\documentclass[10pt,letterpaper,conference]{llncs}

\usepackage{graphicx}
\usepackage{paralist}
\usepackage{lipsum}
\usepackage{amsmath}
\usepackage{amsfonts}
\usepackage{xspace}
\usepackage{changebar}
\usepackage{rotating}
\usepackage{amsmath}
\usepackage{mdwlist}
\usepackage{tikz}
\usepackage{breqn}
\usepackage{caption}
\usepackage{wrapfig}
%\usepackage{times}

%%% algorithm 
\usepackage[linesnumbered,vlined,ruled]{algorithm2e} 
\newcommand{\Cla}{\textit{Cla}}
\newcommand{\T}{{\cal T}}
\newcommand{\M}{{\cal M}}
\renewcommand{\L}{{\cal L}}
\renewcommand{\l}{\ell}
\renewcommand{\d}{\delta}
\newcommand{\m}{\mu}
\newcommand{\F}{{\cal F}}
\newcommand{\D}{{\cal D}}
\renewcommand{\S}{{\cal S}}
\newcommand{\ins}{\textit{Ins}}
\newcommand{\func}[1]{\texttt{#1}}
\newcommand{\cmd}[1]{\texttt{#1}}
\newcommand{\cmdvar}[1]{\textsf{#1}}
\newcommand{\fld}[1]{\textit{#1}}
\newcommand{\var}[1]{\textit{#1}}
\newcommand{\val}[1]{\texttt{#1}}
\newcommand{\fnclty}[1]{\textit{\textsf{#1}}}
\newcommand{\sfnclty}[1]{\textit{#1}}
%% algorithm



\newcommand{\specialcell}[2][c]{%
  \begin{tabular}[#1]{@{}c@{}}#2\end{tabular}}

\newcommand{\eat}[1]{}
\newcommand{\ie}{\textit{i.e.},\xspace}
\newcommand{\eg}{\textit{e.g.},\xspace}

%\newcommand{\comment}[2]{\marginpar{\tiny\textcolor{blue}{\textsf{#2}}}
%\textcolor{blue}{#1}}
\newcommand{\ncomment}[2]{\marginpar{\tiny\textcolor{blue}{\textsf{#2}}}
\textcolor{blue}{#1}}
\newcommand{\comment}[2]{#1}

\renewcommand{\sfdefault}{cmss}
\renewcommand{\ttdefault}{cmtt}

\newcommand{\stitle}[1]{\noindent\textbf{#1}\hspace{1ex}}

\renewcommand{\captionfont}{}
\renewcommand{\captionlabelfont}{\bf}

%\def\baselinestretch{0.98}

% add some page numbers for submission
\pagestyle{plain}

\begin{document}

\title{Logging-in Insecurely: Reverse-Engineering  the Smart-Card Application
  Protocol Data Unit}
  
  \eat{ VS 2)Secure Logging-in: How insecure should you be? vs 3)Securely log logging-in over an insecure reversed-engineered Communication  Layer  vs 
  4)Turning secure logging-in against you: Reverse Engineering the Smart-Card Application
  Protocol Data Unit4 possible c_logIn "friendlier" titles.  
  Also,had to cut 2,5 pages from the paper to reach the page limit. }

\author{
  % double-blind -- no authors
}

\eat{
\author{
  \fontsize{11}{11}\selectfont\upshape
  Andriana Gkaniatsou
  \vspace{1.6mm}\\
  \fontsize{10}{10}\selectfont\itshape
  School of Informatics\\
  University of Edinburgh, UK
  \vspace{1.2mm}\\
  \fontsize{9}{9}\selectfont\ttfamily\upshape
  a.e.gkaniatsou@sms.ed.ac.uk
  \and
  \fontsize{11}{11}\selectfont\upshape
  Fiona McNeill
  \vspace{1.6mm}\\
  \fontsize{10}{10}\selectfont\itshape
  Department of Computer Science\\
  Heriot-Watt University, UK
  \vspace{1.2mm}\\
  \fontsize{9}{9}\selectfont\ttfamily\upshape
  f.mcneill@hw.ac.uk
  \and
  \fontsize{11}{11}\selectfont\upshape
  Alan Bundy
  \vspace{1.6mm}\\
  \fontsize{10}{10}\selectfont\itshape
  School of Informatics\\
  University of Edinburgh, UK
  \vspace{1.2mm}\\
  \fontsize{9}{9}\selectfont\ttfamily\upshape
  a.bundy@ed.ac.uk
}
}

\author{}
\institute{}

\maketitle

\begin{abstract}
   Smart-cards are considered as one of the most secure,
  tamper-proof, and trusted devices for implementing confidential
  operations, such as secure log-in, for financial, communication,
  security and data management purposes. The commonly used RSA
  PKCS\#11 standard defines the Application Programming Interface for
  cryptographic devices such as smart-cards. Though there has been
  work on formally verifying the correctness of the implementation of
  RSA PKCS\#11, little attention has been paid to the low-level
  cryptographic protocols that implement it. We show how
  %\func{C\_logIn}, the 
  essential functions to gain access to the
  card's private objects and perform cryptographic functions can be
  compromised through reverse-engineering traces of the low-level
  communication between a smart-card and the outside world.
    
  We present REPROVE: a proof-of-concept system to analyze and provide
  insight on how specific cryptographic RSA PKCS\#11 functions are
  translated in the low-level communication of the smart-card. REPROVE
  is function-independent, does not require physical card access as it
  reverse-engineers communication traces. REPROVE deals with both
  standard-conforming and proprietary implementations. To the best of
  our knowledge, REPROVE is the first effort to address proprietary
  implementations. We showcase REPROVE's efficiency at successfully
  analyzing the implementation and discovering the security
  vulnerabilities of a card by focusing on the \func{C\_logIn}
  function. Furthermore, we provide evidence of the generality of our
  technique by successfully applying it to reverse-engineer other
  functions as well.
  %\ncomment{In this paper we use the
  %  \func{C\_logIn} function to showcase REPROVE's efficiency on
  %  successfully analyzing the implementation and hence discovering
  %  security vulnerabilities of the card.}{showcase?}
\end{abstract}


\begin{keywords} Smart-card reverse-engineering, PKCS\#11
  low-level attacks, APDU formal modeling, APDU attacks.
\end{keywords}

\input{introduction}
\input{background}
\input{methodology}
%\input{example}
\input{evaluation}
\input{conclusions}




\bibliographystyle{abbrv}
\bibliography{references}

%\appendix

%\input{example}

\end{document}
